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ABSTRACT 


The present invention provides a data rate controller system 
for determining the coder used, and hence the data rate, for 
a plurality of channels in an associated network. Each 
channel provides statistical information about an associated 
signal to a central controller (or call/resource manager). The 
controller considers the information and sends control 
instructions to each channel for selecting an appropriate 
coder and/or data rate. The statistical information might 
include lost-frame rate, jitter, call event discrimination, and 
system resource utilization. By considering each channel 
&om a centralized standpoint, the network can be optimized 
according to network capabiUties and channel resource 
capabilities. A profile might also be used where each channel 
autonomously chooses a coder based upon background noise 
derived fi:om the source signal. 
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DAIA RATE CONTROLLER 

RELATED APPUCAnONS 

[0001] The present applicatioa is a continuation-in-part of 
co-pending U.S. patent application Ser. No. 09/522,185, 
filed Mar 9, 2000, which is a continuation-in-part of co- 
pending application Ser. No. 09/493,458, filed Jan. 28, 2000, 
which is a continuation-in-part of co-pending application 
Scr. No. 09/454,219, filed Dec. 9, 1999, priority of each 
application which is hereby claimed under 35 U.S.C. § 120. 
All these applications are expressly incorporated herein by 
reference' as though set forth in full. 

HELD OF THE INVENTION 

[0002] The present invention provides a system to control 
the data rate used by an end device in order to manage 
available resources and provide sufficiently high voice qual- 
ity. In particular, the device might exist on a network with 
other such devices, and the data rates of each will be 
managed. 

BACKGROUND OF THE INVENTION 

[0003] Internet protocol (IP) networks, and the like, for 
providing data communication among a plurality of com- 
puters are well-known. Such networks facilitate the transfer 
of data files, audio information and video information, as 
well as any other information that may be represented in 
binary form among the plurality of computers. 

[0004] Networks can be conveniently divided into two 
broad categories, based upon their size. A local area network 
(LAN) is a group of computers which is connected so as to 
facilitate the sharing of applications, data and peripherals. 
Local area networks are generally confined to a single 
building or a small group of buildings. 

[0005] A wide area network (WAN) is made up of a 
plurality of LANs which is cormected together so as to 
facilitate communication therebetween. A WAN may cover 
a dtyj a state, a country or even be intemational in scope. 
The Internet is an example of a WAN that includes more than 
2,000 separate packet-switched networks that are located all 
over the world. 

[0006] The popularity of networks, such as the Internet, 
has increased the desire for additional network services, 
such as network telephony. The vast, high bandwidth net- 
work provides an ideal medium for audio communications. 
The nature of such telephone devices is to process voice 
signals that might come in over the network, typically as 
digital packets of information, or the like. To process such 
signals, various computing and processing devices are used, 
typically in the form of integrated circuit configurations. 
These devices are often capable of handling multiple chan- 
nels of information. Alternatively, multiple channels might 
be processed using multiple devices distributed across a 
network. 

[0007] For telephony and voice applications, packet-based 
networks are becoming more widely used. In the past, it was 
often difficult to guarantee sufficient bandwidth or a certain 
"quality of service** that might be needed to accommodate 
real-time voice signals (that are broken into packets). How- 
ever, known solutions have been developed which address 
various problems associated with transmitting voice over 


packet networks, including, for instance, voice over IP 
(Internet Protocol), voice over ATM (asynchronous transfer 
mode), and voice over frame relay. 

[0008] Prior art solutions include voice coders (i.e., par- 
ticularized hardware and software devices) that can be 
applied to packet-based voice systems. Voice coders are 
configured to process and encode incoming voice signals at 
certain data rates. In general, if a higher data rate is used 
(i.e., more voice samples are taken), then the voice coder 
does not need to be as complex. In other words, fewer 
hardware components might be employed, or the software 
associated with the device might be less complex. Con- 
versely, if a lower data rate is used, the voice coder is 
generally more complex since more compression needs to be 
performed on the signal. 

[0009] This data rate can be varied, depending upon the 
input signal or source being supplied to the device. For such 
devices, the term variable bit rate (VBR) has been defined as 
follows: A VBR encoder outputs a bit stream which may 
have a variable number of bits in successive firames. That is, 
each frame may contain a different number of bits relative to 
the last fi:ame. Bit-rates may vary, for example, in large 
predefined increments/decrements, or the bit-rates may vary 
by as little as one-bit resolution. The variability in bit rate 
may be either network controlled or source controlled 
according to the input audio signal, 

[0010] Source controlled rate (SCR) devices use the 
source to vary the bit rate. For instance, during a normal 
telephone conversation, the participants alternate speaking 
so that, on average, each direction of transmission is occu- 
pied 50% of the time. SCR is a mode of operation where the 
speech encoder encodes speech frames containing only 
background noise with a lower speech rate than might be 
used for encoding speech. A network may also vary its 
transmission scheme to take advantage of the varying bit 
rate. Benefits provided therein include: (a) increases battery 
life and/or reduces power consumption of the associated 
processing system, and (b) the average required bit-rate is 
reduced, thereby leading to a more efficient transmission 
with decreased load and hence increased capacity. 

[0011] Encoders conform to various standards proposed 
through the International Telecommunication Union (ITU) 
and European Telecommimications Standards ' Institute 
(ETSI). The ITU Telecommunication Standardization Sector 
(ITU-T) is one of the three Sectors of the ITU. The ETSI 
focuses moreso on European standards. Hie mission of the 
ITU and the ETSI is to ensure efficient production of high 
quality standards covering certain fields of telecommunica- 
tions. Table 1 (ITU) and Table 2 (ETSI) show certain 
representative encoding standards: 

TABLE 1 

rrU-T Standard Encoders 
Name Annex (if appropriEte) .^jproximate data rate(s) 


0.728 
0.729 


G.711 
G.726 


A 
B 
D 
B 


16 Kbps/12.8 Kbps 

8 Kbps 

VAD 

6.4 Kbps 

lis Kbps 

64 Kbps 

16/24/32/40 Kbps 
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TABLE 1 -continued 



nXJ-T standard Encoders 

Name 

Annex (if appropriate) Approximate data ra.te(s) 

0.723.1 

6.3 Kbps 


5.3 Kbps 


A VAD (voice activated device) 

[0012] 



TABLE 2 

ETSI-Standard cacodeis 


GSM-AMR 4-12 Kbps 


GSM-FR/EFR 13 Kbps 


GSM-HR 6.4 Kbps 

[0013] 

These representative encoders are part of a growing 


list of standards, with each different device being used 
according to its specification of abilities for a given situa- 
tion. For instance, G.728 is an international voice compres- 
sion standard from ITU and has rapidly gained acceptance 
for many applications including: satellite, cellular, and 
video-conferencing systems. G.728 is specified as part of the 
H.320 international video-conferencing standard. One rea- 
son for its rapid acceptance is that G.728 delivers the same 
toll-quality voice as 32 Kbps ADP(^ (adaptive differential 
pulse-code modulation), but in only half the bandwidth. 
Note that ADPCM is a technique for converting sound or 
analog information to binary information (a string of O's and 
I's) by taking frequent samples of the sound and expressing 
the value of the sampled sound modulation in binary terms. 

[0014] Referring to FIG. 6 of the above-incorporated 
references entitled "\bice and Data Exchange over a Packet 
Based Network with Resource Management," and "Voice 
and Data Exchange over a Packet Based Network," respec- 
tively, the encoders would be located within the voice 
encoder block 82. The encoders would be implemented via 
either hardware and/or software, depending upon the con- 
figuration that was implemented. 

[0015] Certain members of this group of representative 
encoders are known to incorporate various aspects of SCR. 
For instance, the ETSI GSM-AMR coder is source con- 
trolled, as well as Qualcom's QCELP coder, and certain 
VAD-Speech coder combinations. Network management 
systems in current use wall normally manage network band- 
width by down^eeding endpoints during congestion. How- 
ever, the various members of this overall collection of 
encoders are not believed to use a collection (or combina- 
tion) of statistical information — that might be derived from 
the network (i.e., the devices in the network and the asso- 
ciated connections) and the source — in order to arrive at a 
data rate decision. It is one important aspect to collectively 
consider the data rate needs of aU of the devices in the 
network. It is also an important aspect to have a system that 
can adjust the rates of each device to thereby create a more 
eflScient throughput of data across the entire system. 

[0016] Accordingly, what is needed in the field is central 
controller coupled with a network of devices which can 
monitor statistical information (or the like) associated with 


each network device. The information might be considered 
alone or in combination with other information and thereby 
adjust the data rate of each device based upon such statistical 
information, 

SUMMARY OF THE INVENTION 

[0017] The present invention provides a system for adjust- 
ing the data rates of various channels within a network of 
devices. Each channel within a device runs a coder that 
conforms to certain standards, depending upon what par- 
ticular coding functions the channel is supposed to perform 
(i.e., voice, data, EAX, etc.). Moreover, certain coders per- 
form better under different adverse conditions, such as noise, 
jitter, lost padcets, etc. Among other things, the different 
coders can operate at different data rates. Selection of the 
appropriate coder for the situation provides for selection of 
an appropriate data rate. 

[0018] The present invention includes a call/resource 
manager (or central controller) that receives statistical infor- 
mation from a plurality of channels associated with the 
manager. The channels provide statistical information to the 
manager about the inbound/outbound signal, the charmel 
resources, and/or the network resources. This information 
might involve certain factors in order to make a coder (i.e., 
data rate) decision. These factors include, but are not limited 
to, estimated lost packet rate, estimated jitter in the network, 
estimated background noise level, estimated network utili- 
zation, and estimated process utilization. The corresponding 
information would be provided by devices such as a lost 
frame rate estimator or a jitter estimator in a voice synchro- 
nizer, a jitter estimator in a voice synchronizer, a call 
discriminator, and/or resource information (from the net- 
work or from the channel processors). These information- 
providing devices might be sub-components of an overall 
system, such as a network telephony device or the like. 

[0019] The manager thereby monitors statistics and events 
from each channel and thereafter generates control instruc- 
tions to be sent to a portion (or all) of the channels. For 
instance,-if a high lost frame rate is indicated, a switch can 
be made on some or aU of the channels to a lower rate coder. 
In an illustrative embodiment, if a high lost frame rate is 
indicated, the packetization interval is reduced. This should 
reduce network congestion, as weU as the high frame loss 
condition. A lower-frame lost condition will improve voice 
quality. If a high jitter rate is detected, then instructions can 
be given to downspeed all or some of the channels. This 
should relieve congestion on the network, which should 
improve jitter performance. If a call discriminator detects a 
certain type of call, then the manager might also consider 
network utihzation and/or system resource utilization in 
order to switch from one mode to another mode (i.e., 
voiceband data mode to FAX relay mode). Background 
noise might also be used by a channel to derive an upspeed 
request, which will be considered by the manager/controller 
in light of network utiUzation and resource utilization. 
[0020] Still another embodiment might utihze channels 
that can autonomously switch to any of a number of coders 
that comprise a set for that channel. The network will 
thereby have profiles that must be satisfied for each network 
path. Based upon badcgroimd noise (or the like), the charmel 
will switch to a preferred coder. After each coder is selected, 
the network requirements will be satisfied according to the 
determined profiles that were used to determine the set of 
coders for each channel. 
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[0021] Accordingly, one aspect of the present invention 
provides for a data rate controller system for providing 
control instructions to a plurality of channels on correspond- 
ing channel devices operating on a network. The system 
includes at least one chaimel that provides statistical infor- 
mation about the associated channel signal. The system also 
includes at least one coder and a central controller. Each 
coder provides for running at a certain data rate on each 
channel device. The central controller interacts with the 
plurality of channels. Statistical information about each 
channel signal is iised by the central controller to determine 
the type of coder that should be run on each channel device. 
The central controller sends a control instruction to each 
channel to facihtate implementation of the coder. 

[0022] Another aspect of the present invention provides 
for a data rate controller system for providing control 
instructions to a plurality of channels on corresponding 
channel devices operating on a network. At least one channel 
has means for detecting background noise conditions, and 
means for providing channel resource utilization and asso- 
ciated network utilization information for each channel. At 
least one coder runs at a certain data rate on ead) channel 
device. A , central controller interacts with the plurality of 
channels. The noise conditions and the resource and network 
utilization information, from each channel, are used by the 
central controller to determine the type of coder that should 
be run on each channel device. The central controller sends 
a control instruction to each channel to facilitate implemen- 
tation of the coder. 

[0023] Still, another aspect of the present invention pro- 
vides for a data rate controller system for allowing a 
plurahty of channels on a network to each select a channel 
coder that fits an associated network profile. The system 
includes a network of channels having a plurality of con- 
nections. The network forms a profile of allowed data rates 
that might flow across the connections. A set of coders is 
associated with each channel on the network. A device is 
associated with each channel for detecting source informa- 
tion. The source information is used by each channel to 
select an appropriate coder fi-om each set of coders, with 
each channel thereafter satisfying the profile. 

[0024] It is understood that other embodiments of the 
present invention will become readily apparent to those 
skilled in the art from the following detailed description, 
wherein shown and described are only example embodi- 
ments of the invention by way of illustration. As will be 
realized, the invention is capable of other and different 
embodiments and its several details are capable of modifi- 
cation in various other respects, all without departing firom 
the spirit and scope of the present invention. Accordingly, 
the drawings and detailed description are to be regarded as 
illustrative in nature and not as restrictive. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0025] Certain aspects and advantages of the present 
invention will be apparent upon reference to the accompa- 
nying description when taken in conjunction with the fol- 
lowing drawings, which are exemplary, wherein: 

[0026] FIG. 1 is a representative block diagram, according 
to at least one aspect of the present invention, of the 
call/resource manager (or central controller) receiving sta- 


tistical information from a plurality of channels and provid- 
ing data rate instructions based upon this information. 

[0027] FIG. 2 is a block diagram, according to one aspect 
of the present invention, of a voice synchronizer/jitter buffer 
that might be contained in an overaU system, having a lost 
packet rate estimator and a jitter estimator. 

[0028] FIG. 3 is a block diagram, according to one aspect 
of the present invention, of a plurality of diannels providing 
lost frame rate information to the call/resource manager, 
with control instructions returned based on this information. 

[0029] FIG. 4 is a block diagram, according to one aspect 
of the present invention, of a plurahty of channels providing 
jitter information to the call/resource manager, with control 
instructions returned based on this information. 

[0030] FIG. 5 is a block diagram, according to one aspect 
of the present invention, of a plurality of diannels providing 
call discriminator event information and/or system resource 
utilization information to the call/resource manager, with 
control instructions returned based on this information. 

[0031] FIG. 6 is a block diagram, according to one aspect 
of the present invention, of a plurality of channels sending 
a request to the call/resource manager for upspeed of the 
data rate, the request being derived fi:om noise information, 
with control instructions returned based on this information. 

[0032] FIG. 7 is a block diagram, according to one aspect 
of the present invention, of standards being invoked for each 
of a plurality of channels, according to profiles that satisfy 
certain network requirements and constraints. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS . 

[0033] The present invention is described below in terms 
of certain preferred embodiments and representative apph- 
cations. The examples provided are intended to be used with 
any communication system that would benefit from having 
a controller that can control the data rates used by various 
devices in a network or system. The controller will be used 
to monitor and interpret various statistical information per- 
taining to the network and its interconnected devices. While 
a certain set of examples is presented in terms of what 
statistical information to \ise, any of a variety of other 
statistical information might also be considered and used to 
adjust the data rates of the various networked devices. 

[0034] The present invention is also intended to apply to 
voice over packet networks, including, but not limited to, 
\foice over IP (VoIP), Voice over ATM (VdATM), voice over 
frame relay and cellular/wireless/PCS networks. The present 
invention describes certain methods involved in performing 
the switch. Certain representative factors are also described, 
which can be used in making the data rate decision. These 
factors include, but are not limited to, the following: (1) 
estimated lost packet rate, (2) estimated jitter in the network, 

(3) estimated background noise level (i.e., source statistics), 

(4) estimated network utilization, and/or (5) estimated pro- 
cessor utilization (either committed or observed). 

[0035] According to such statistics, a system is provided 
to control the rate of an end device in order to manage 
resources available and thereby obtain a high voice quality 
across each device in the network. These statistics can be 
broken down into source statistics and network statistics. 
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Source statistics (i.e., background noise level and the like) 
arc derived directly ftom the incoming sigpal and do not 
require any information from/about the other devices in a 
system. Network statistics, however, require the system to 
have a central manager, which manages all of the channels 
being aggregated onto a network. The central manager might 
similarly include a host, call manager, call agent, or the like. 
The manager will serve to monitor statistics and events from 
each channel and thereafter make rate (i.e., bandwidth) 
decisions based on a multitude of factors (including, for 
instance the factors 1-5 shown above). 

[0036] FIG. 1 next shows an example data rate controller 
system 100. Note that each channel may reside on the same 
physical device or on multiple devices. The Call/Resource 
Manager (or central controller) 102 is shown receiving 
various signal information from a plurality of channels. 
Channel 1 (104) is shown to provide certain statistical 
information to the manager 102, including source rate 
request 106, call discriminator request 108, jitter 110, lost 
frame rate 112, and system resource utilization 114. The 
statistical information is not strictly limited to the elements 
shown and might include other information as indicated by 
the continuation indicator 115. The manager 102 uses this 
information to thereafter send control instructions 116 back 
to channel 1 (104). A second chaimel 120 is shown sending 
a similar set of information 122 to the manager 102 and then 
receiving control instructions 124 back from the manager 
102. Any number of other channels might be included, up to 
and including channel N (130). Channel N also sends a 
similar set of information 132 back to the manager 102 and 
receives control instructions 134. 

[0037] Representative examples are next described for 
utilizing each statistical piece of information listed above, 
namely Lost Frame Rate, Jitter, Call Discriminator Request, 
Estimated Background Noise, and Network Profile Support. 
The present invention is not intended to be strictly limited to 
these statistical pieces of information, as other forms of 
statistical information might also be used. 

[0038] Lost Frame Rate (see FIG. 1, 112)— In a packet 
based system, frames of data are processed in a sequential 
fashioa Occasionally, frames are lost or dropped during the 
process. A lost frame can result in temporary loss of the 
voice and/or data signal over a transmission hne. Generally, 
the lost frame rate is a measure (or estimate) of the amount 
of frames that might be dropped by a system and is often 
calculated as a percentage of the total amount of incoming 
frames. 

[0039] Referring again to FIG. 6 of the incorporated 
references entitled "Voice and Data Exchange over a Packet 
Based Network with Resource Management," and "Voice 
and Data Exchange over a Packet Based Network," respec- 
tively, the lost packet estimator will generally be included in 
the \bice Synchronizer block 90. FIG. 2 shows this device 
200 configured as both a voice synchronizer and jitter buffer. 
The arriving packets 202 enter the device and are processed 
by both the lost packet rate estimator 204, as well as the jitter 
estimator 206. The result 205 from the lost packet rate 
estimator 204 wiU be used by the central controller (FIG. 1, 
102) as a standard piece of statistical information. A jitter 
estimator 206 is also shown, with the result 207 also being 
used by the central controller 102. TTie respective results 
208, 209 of each sub-part (204, 206) of the voice synchro- 


nizer^ itter buffer 200 are sent to the voice decoder (see FIG. 
6, element 96 of the incorporated reference). 

[0040] 39 According to one aspect of the present inven- 
tion, if aU of the chaimels are using a voice compression 
algorithm with low complexity (i.e., ITU-T standard G.711), 
and the lost frame rate is high on all channels (for instance 
>2%), then a switch should be made to a lower data rate 
encoder. FIG. 3 serves to illustrate such circumstances. The 
Call/Resource manager 302 is shown receiving lost frame 
rate information 303, 305, and 307 from eada respective 
channel 304, 306, and 308. If each channel has a lower rate 
coder available — particularly a coder with better lost frame 
characteristics (i.e., G,729 Annex E at 11.8 kbps), then the 
resource manager 302 will send some form of control 
insuiictions (i.e., 310, 312, or 314, respectively) back to 
each appropriate channel. The instructions wiU dictate 
whether the coder rate should be switched on a portion of the 
channels, or on all channels, which are imder the control of 
the manager 102. 

[0041] By switching to a lower rate encoder, overall 
congestion on the network should be reduced. This is 
because the lower rate encoder pushes fewer bits out onto 
the transmission path (or network paths) for an equivalent 
amount of incoming voice/data signal. In turn, the lower rate 
should help to reduce the high frame loss condition. By 
lowering the frame loss rate, the voice quality will thereby 
be improved (despite using the lower rate encoder). In an 
illustrative embodiment of the present invention, if a switch 
is made to a lower rate encoder as a restilt of a high lost 
frame rate, a lower packetization interval is used, and this 
will minimize the temporal effect of a single lost frame. 

[0042] In this example, the high-loss frame rate is detected 
on inbound channels. Note that each channel is shown to 
function as either an inbound 220 or outbound 222 signal. 
However, there may or may not be congestion on outboimd 
channels. Accordingly, this system should also signal the 
call resource managers to send instructions to decrease the 
bandwidth used by the end devices (i.e., the devices employ- 
ing the channel on the network). 

[0043] Alternatively, the end devices might be configured 
to switdi to a different voice coder when a change in the 
egress rate is detected. For instance, if the egress rale 
increases, then a higher rate coder might be used. Con- 
versely, if a lower egress rate is detected, then a lower rate 
coder might be used. This would provide for maximum 
performance of voice quality in the system while accotmting 
for bandwidth capabilities of the network and devices within 
the network. 

[0044] Jitter (see FIG. 1, 110>— Jitter might be defined as 
the deviation in, or displacement of, timing of a digital 
signal. For instance, if a signal packet is expected at a certain 
time, and the packet comes in al a later time, then the jitter 
might be expressed as this time delay, 

[0045] Causes of jitter include (among other things) pro- 
cessing delay, queueing of packets in network equipment, 
and diSfferent delays due to the possibly different paths 
packet take while traversing the network. In audio signals, 
jitter -can introduce phase distortion or other undesired 
effects in the signal and loss of transmitted data between 
network devices. The amount of allowable jitter depends 
greatly on the application at hand. 
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[0046] FIG. 4 next shows the system configuration 400 
where the CaU/Rcsouroe manager 402 receives jitter infor- 
mation from each channel. Channel 1 (404) is shown send- 
ing information to the manager 402, thereby indicating 
whether the jitter 406 is above a set limit or not. For instance, 
the set limit might test if the jitter is greater than 50 msec on 
some or all of the diannels considered. Similarly, channel 2 
(408) is shown sending jitter information 410 to the manager 
402, and channel N (412) is shown sending jitter information 
414 to the manager 402. Based upon the information gath- 
ered from all channels, the manager (or controller) 402 
makes a decision to downspeed all or some channels to a 
lower data rate. This is shown as certain control instructions 
(i.e., 420, 422, and 424) being sent to facihtate lowering the 
encoder rate. One coder that might be used to satisfy the 
downspeed instructions includes the ITU-T standard G.726 
running at 32 Id^ps. Using a coder at this data rate should 
serve to relieve congestion on the network. Less congestion 
will, in tum, subsequently improve the jitter performance. 

[0047] Generally, the high jitter is detected on inbound 
packets 430. The rate change thereafter affects outbound 
packets 432. Similar to the end device described above, the 
system should also signal the call resource manager(s) 402 
to decrease the bandwidth used by the end devices. Alter- 
natively, the end devices could switch voice coders when an 
egress rate change is delected, 

[0048] Call Discriminator Request (see FIG, 1, 108), and 
System Resource UtiUzation (see FIG. 1, 114 )— Elements 
108 and 114 in FIG. 1 further show that information derived 
from a call discriminator, and system resource utilization, 
might also be used to adjust the data rate of the channels. A 
representative call discriminator is shown as element 68 in 
FIG. 6 of the incorporated references entitled "Voice and 
Data Exchange over a Packet Based Network with Resource 
Management," and "Voice and Data Exchange over a Packet 
Based Network," respectively. FIG, 5 of the present inven- 
tion shows a representative system configuration 500 (as per 
the model of the previous examples). For example purposes 
only, channel 1 (504) might be assumed to be configured 
with a voice coder (i.e., G,729, or the like), and the call 
discriminator might thereafter detect a FAX call. The voice 
system running on channel 1 provides call discriminator 
events 506 to the controller/resource manager 502. Each 
channel also provides system resource utilization informa- 
tion 505 to the manager 502. Channels 2 (508) through N 
(512) also provide call discriminator events (510 and 514, 
respectively) and system resource utilizations (509 and 513, 
respectively) to the resource manager 502. 

[0049] Based on network utilization and/or system 
resource utilization (505, 509, 513) (i.e., MIPs, memory, or 
the like), certain control instructions (or commands, 520, 
522, and 524, respectively) are sent from the manager 502 
to each channel 504, 508, and 512. The control instruction 
facilitates the channel switdiing from one mode to another. 
For this particular example, the mode might switch from a 
voice mode to a voiceband data mode. Such switching might 
include running a G.711 voice coder, and setting the jitter 
buffer to a non-adaptive mode. The diannel switching might 
additionally facilitate switching to FAX relay. 

[0050] As described above, a lower complexity encoder 
produces more bits and requires more bandwidth in order to 
send data. A high complexity encoder produces fewer bits 


because the compression algorithm is more complicated. 
The needs of each device need to be weighed against the 
capabilities of the system. For instance, a voice coder like 
G.711 has a relatively low complexity and therefore requires 
a relatively higher amount of bandwidth to send data. FAX 
relay is higher complexity than a G.711 coder and therefore 
requires more system resources. 

[0051] Accordingly, each of the channels on the network 
is analyzed to determine the overall capabilities of the 
system. If it is determined that the network congestion is 
high, and the system resource utilization is low, then FAX 
relay might be used. If the network congestion is low, but the 
system resource utilization is high, then the voiceband data 
mode might be used. 

[0052] Still another case might find both the network 
being congested, and the processor being overworked. In 
such a case, the FAX call might simply be dropped. Note 
that high network utilization implies that bandwidth is not 
available to carry the FAX call via G.711. Conversely, high 
resource utilization means that there may not be enough 
resources to run the complex FAX relay. Accordingly, the 
entire call might need to be dropped in order to satisfy the 
system capabilities. 

[0053] The above example is meant to be illustrative only. 
Other call events might also be considered, in light of system 
resource utilization, in order to determine control instruc- 
tions to send to a portion of the channels or all of the 
channels. 

[0054] As before, generally the call event type is detected 
on inbound signals 530. Any rate change will affect out- 
bound packets, and the system should signal the call 
resource managers to decrease the bandwidth used by the 
end devices. Again as before, the end devices might switch 
voice coders when an egress rate change is detected. 

[0055] Estimated background noise (derived from 
source) — ^The backgrotmd noise of an inbound signal can be 
derived fixam the source without each channel needing to 
communicate with the central controller. This background 
noise (alone) can be used to determine whether a channel (in 
an associated device) should switch from one data rate to 
another. However, certain advantages might also be derived 
by considering the system resource utilization of each device 
on the network. 

[0056] FIG. 6 shows an example of certain representative 
elements 600. An inbound signal 640 (fi^om a source or the 
like) comes into channel 1 (604). Channel 1 might be 
running G723.1 at 5.3 kbps and thereafter detect high 
background noise conditions (i.e., >45 dBm). The channel 
will send a request to upspeed 606 to be considered by the 
Call/Resource manager 602. The request to upspeed might 
inchide a request to switch to G.728 at 16 kbps, or sunilar 
data rate, which is higher than the present data rate. Hie 
call/resoTirce manager 602 wiU also consider the system 
resource utilization 608. Hiis might include processor uti- 
lization and/or network utiUzation. Note that the higher data 
rate standard will require more bandwidth. If the network 
utilization is low, then there is bandwidth available for 
G.728 or the like. If the processor utilization is low, then 
there is processor bandwidth available for running G.728 or 
the like. If these representative utilization conditions are 
satisfied, then the controller grants the request via the control 
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instructioa(s) 610. A similar situation is shown for channel 
2 (620), with a respective request to upspeed 622 and system 
resource utilization 624 being sent to the call/resource 
manager 602. The granting of the request (or not) by the 
manager 602 is shown, respectively, as 626 and 636. 

[0057] Support for Network Profiles— Still another 
example might utilize a profile of possible coders that would 
be supported by a particular network configuration. FIG. 7 
shows certain representative elements 700 to illustrate the 
usage of such profiles. A plurality of chaimels is shown 
having at least one channel coder associated with each 
channel. Generally each channel will have a set of coder 
standards. Channel 1 (702) is shown to have at least G.711, 
G.729, and so forth. Channels 2 (704) through N (706) also 
have these representative coders (while others could be 
used). 

[0058] Each path 710, 712, and 714 in the network 708 
will have a certain profile of capabilities that have been 
derived from various factors, including, for instance, the 
network capability (i.e., each path in the network or the 
overall network), and the processor resource capabilities of 
the various devices using the channels. The profiles should 
be designed so that if each channel chooses to run a certain 
standard, the network and processor resources will be within 
the capabilities of the system. 

[0059] For instance, channel 1 might be running the G,711 
standard at 64 kbps. The channel might thereafter detect 
very low badcground noise conditions and autonomously 
switch to a lower rate standard within channel set, such as 
the G.729 standard, in order to conserve processor/MIPs 
resources. Channel 2 (704) through channel N (706) might 
perform sinular switching from one standard to another, 
based upon the background noise associated with each of 
these channels. The profiles available for each of these 
coders will provide a workable system configuration for any 
selected coder, even though the coders are autonomously 
selected by each separate channel. 

[0060] By implementing any of these example represen- 
tations, a higher quality system might be maintained at a 
lower cost. By sharing resources and trading off network 
bandwidth, a higher system utilization might be achieved, 
which in turn can increase quality of the voice/data trans- 
mission over a channel. 

[0061] Although certain exemplary embodiments of the 
present invention have been described, it should not be 
construed to limit the scope of the appended claims. For 
example, the present invention can be implemented by both 
a software embodiment or a hardware embodiment. Those 
skilled in the art will understand that various modifications 
may be made to the described embodiment. Moreover, to 
those skilled in the various arts, the invention itself herein 
will suggest solutions to other tasks and adaptations for 
other applications. It is therefore desired that the present 
embodiments be coasidered in all rejects as illustrative and 
not restrictive. It is therefore intended that the following 
claims be interpreted as covering all such alterations and 
modifications as fall within the true spirit and scope of the 
inventioa 

1. A data rate controller system for providing control 
instructions to a plurality of diannels on corresponding 
channel devices operating on a network, the system com- 
prising: 


at least one diarmel providing statistical information 
about the associated channel signal; 

at least one coder provided for nmning at a certain data 
rate on each channel device; and 

a central controller for interacting with the plurality of 
charmels, 

wherein statistical information about each chaimel signal 
is used by the centra] controller to determine the type 
of coder that should be run on each channel device, 
with the central controller sending a control instruction 
to each channel to facilitate implementation of the 
coder. 

2. The data rate controller of claim 1, wherein the statis- 
tical information includes at least lost-fi-ame rate estimation. 

3. The data rate controller of claim 2, wherein the central 
controller determines if the lost-frame rate is above a set 
limit, and generates the control instruction based upon this 
condition. 

4. The data rate controller of claim 3, wherein the control 
instruction causes a lower-rate encoder to be used on at least 
a portion of the channels. 

5. The data rate controller of claim 4, wherein the lower 
rate encoder is determined to fit within the processor 
resources of the channel. 

6. The data rate controller of claim 5, wherein the lower- 
rate encoder is determined to fit within the resources of the 
network. 

7. The data rate controller of claim 4, wherein the control 
instruction causes a lower packetization interval to be used 
on at least a portion of the channels. 

8. The data rate controller of claim 3, wherein the set limit 
is approximately two percent. 

9. The data rate controller of claim 1, wherein the statis- 
tical information includes at least jitter estimation. 

10. The data rate controller of claim 9, wherein the central 
controller determines if the estimated jitter is above a set 
limit, and generates the control instruction based upon this 
condition. 

11. The data rate controller of claim 10, wherein the 
control instruction causes a lower-rate encoder to be used on 
at least a portion of the channels. 

12. The data rate controller of claim 11, wherein the lower 
rate encoder is determined to fit within the processor 
resources of the channeL 

13. The data rate controller of claim 12, wherein the 
lower-rate encoder is determined to fit within the resources 
of the network. 

14. The data rate controller of claim 10, wherein the set 
Limit is approximately 50 msec. 

15. The data rale controller of claim 1, wherein the 
statistical information includes at least call discriminator 
events and system resource utilization. 

16. The data rate controller of claim 15, wherein the 
system resource utilization includes at least network con- 
gestion and processor congestion. 

17. The data rale controller of claim 16, wherein the 
central controller determines a coder that can support the 
call in light of the system resource utilization, and generates 
the control instruction based upon this determined coder. 

18. The data rate controller of claim 17, wherein the 
control instruction causes a lower-rate encoder to be used on 
al least a portion of the diannels if the network congestion 
is high. 
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19. The data rate controller of claim 17, wherein the 
control instnictioD causes a lower complexity coder to be 
used on at least a portion of the channels if the processor 
congestion is high. 

20. A data rate controller system for providing control 
instructions to a plurality of channels on corresponding 
channel devices operaling on a network, the system com- 
prising: 

at least one channel with means for detecting background 
noise conditions, and means for providing channel 
resource utilization and associated network utilization 
information for each channel; 

at least one coder provided for running at a certain data 
rate on each channel device; and 

a central controller for interacting with the plurality of 
• channels, 

wherein the noise conditions and the resource and net- 
work utilization information, from each channel, are 
used by the central controller to determine the type of 
coder that should be run on each channel device, with 
the central controller sending a control instruction to 
each channel to facilitate implementation of the coder. 

21. TTie data rate controller system of claim 20, wherein 
the background noise conditions are determined to be 
greater than a set level, 

22. The data rate controller system of claim 21, wherein 
the set level is approximately 45 dBm. 


23. The data rate controller system of claim 20, wherein 
the control instiuction faciliatcs upspeeding the coder if the 
network utilization is low. 

24. The data rate controller system of claim 23. wherein 
the control instruction facilitates using a more complex 
coder if the resource utilization information is low. 

25. A data rate controller system for allowing a plurality 
of charmels on a network to each select a channel coder that 
fits an associated network profile, the system comprising: 

a network of channels having a plurality of connections, 
whereby the network forms a profile of allowed data 
rates that might flow across the connections; 

a set of coders associated with each channel on the 
network; and 

a device associated with each channel for detecting source 
information, 

wherein the source information is used by each channel to 
select an appropriate coder from each set of coders, 
with each channel thereafter satisfying the profile. 

26. The data rate controller system of claim 25, wherein 
the source information includes background noise. 

27. The data rate controller system of claim 25, wherein 
each channel switches to a selected coder in an autonomous 
manner from other channels. 

♦ * * * * 
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